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ABSTRACT 



The use of standard procedures in development and documentation 

of automated systems has become a necessity. Many activities in 

% 

Government and indust y are expending a large effort in manpower 
and costs in duplicating procedures and documentation that may have 
been prepared many times before. An effort has been made in this 
paper to describe an approach to a standardized system of develop- 
ment and record keeping that would preclude duplicating effort 
previously expended in the same area. 

The paper follows the development of an automated system from 
its inception to completion recommending methods for recording 
procedures used in automating a functional process. 
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CHAPTER I 



A. INTRODUCTION 

In developing an automated system, whether it be military or 
commercial, the proper planning, analysis and design is dependent 
upon adequate data, systematically developed and properly docu- 
mented. The purpose of this paper is to present the logical devel- 
opment of an automated system from its inception to completion. 
Emphasis will be placed on proper and timely documentation require- 
ments . 

Thousands of automated systems have been and are being de- 
signed by government and industry. Computers are becoming contin- 
ually more sophisticated and the output (reports, display, etc.) 
of these automated systems are extremely well developed. The "State 
of the Art" for automated systems had advanced much more rapidly 
than its administrative development and documentation. In other 
words, we have ultramodern systems and archaic methods of admin- 
istrative control and record keeping. Part of the reason for this 
is the lack of glamour to this extremely necessary segnent of 
development. It may never be glamorous, but it must be performed, 
else we build on a foundation of sand. 

Two major questions arise in administrative development and 
documentation. These are, who should control this development and 
how must it be controlled. 

In a recent Senate Report to the President on "...The manage- 



ment of Automatic Data Processing in the Federal Government** 

Many of the problems in the field of Data Processing Management 
were discussed. It outlined the problem of who should control 

administrative development as follows? 

‘ 

The assignment of appropriate roles to the different 
echelons of management in the Federal Government is of great 
importance. Some computer applications, particularly those 
involved in administrative functions; have a great deal in 
common and conceivably could be subject to greater central- 
ization. On the other hand, the more significant computer 
applications are integral parts oj agency programs; accord- 
ingly, each is a unique application and its management is a 
responsibility of those officials charged with mission 
* accomplishment. The problem then becomes one of improving 

ji the effectiveness and the economy of computer utilization, 

both within an executive agency and in the government as a 
whole, without derogating the proper authorities and 
responsibilities of managers in the line. 

This problem has not gone unnoticed in that the report provides 

for some macro -type solutions by reconmending that? 

1. The Bureau of the Budget will develop a broadly based 
program of continuous evaluation of computer systems, to 
provide an assessment of accomplishments and to serve as a 
recurring source of' information for the development or 
revision of policies and guidelines. The responsibility for 
conducting evaluations and preparing appropriate reports will 
rest with the agency heads, in accordance with their normal 
management responsibilities, 

2. The Bureau of the Budget will develop criteria to assist 
in evaluating both systems design and various aspects of 
system performance. 

3. Agencies should develop master data-processing plans at 
appropriate levels, to serve as guides in the orderly devel- 
opment of systems and to assure the most effective use of 
staff resources available for that development. 

4. The Department of Commerce, through the National Bureau 
of Standards, should expand the advisory service currently 
being provided to agencies in the analysis and design of 
computer-based systems. Its resources allocated for this 
purpose should be increased to the extent required to meet 
such needs as fully as possible. 

The report also emphasizes the necessity of managers to concern 
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themselves with all aspects of Data Processing from the determina- 
tion of objectives to the utilization of the end product. 

One of the major concerns of the data processing manager is 
that of documentation criteria and documentation standards. 
Recognition of the importance of these problems is emphasized in 
the Senate report in that two of the twelve major actions alluded 
to them - i.e. - action number 7 and 12 noted below. 

#7. Strengthen Government support of programs initiated 
by the American Standards Association to achieve needed 
compatibility among automatic data processing equipment and 
systems . 

#12. Propose the enactment of legislation by Congress 
which would: . . . 

(b) strengthen the authorities for the development, 
testing and implementation of standards; the Performance of 
Research in computer sciences and the provision of advisory 
services by the National Bureau of Standards. 

Standardization is described by Dr. Otto Frank'*' as 

The regularization or establishment of what is approved as 
good or valuable. It aims to reduce the uncoordination, 
confusion and waste that ensue from a needless variety of 
products or methods, and to discourage the persistence of 
practices which experience has shown to be less good than 
the best. 

In other words, use procedures that are generally accepted 
in the field of management and data processing. How does one know 
what is generally accepted as being "Good or Valuable?" The 
answer to the question has not been fully considered, however: 

The Federal Government is now vitally interested in the answers. 

A step toward an acceptable answer is being made as a result of 
the above mentioned Senate Report which states in part: 



Frank, 0., Modern Documentation and Information Practices, 
International Federation for Documentation, 1964, 1. 
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Figure 1 



A related problem (to compatability of computer systems) 
is the lack of standardization of data elements in common 

use and the codes used represent those elements Today, 

the close interrelationship among systems of different agencies 
or the centralized summarization of data common to all agencies, 
demands that data elements or codes representing an element 
of data be standard for the Government .” [jpQ 

In one area of standardization, that is the area of flow charting 

<*> 

automated systems, the Department of Defense has developed standard 
flow charting symbols. Figure 1 displays these standard symbols. 

An example of where the problem of lack of standardization 
exists is the area of command and control in the Department of 
Defense. The Army, Navy, and Air Force each have their own method 
of preparing documents. There is some effort to develop standard 
programming techniques and language through joint standardization 
committees within the Department of Defense. However, there is a 
great deal still to be accomplished in the area of documentation 
standards. The Army developes the majority of their automated 
programs ”in house” without the use of contractor assistance. The 
Navy uses a combination of ”in house” effort and contractor assist- 
ance. The Air Force uses mainly contractor effort in development. 

A more detailed look at both problems of ,# who” and ”how” has 

2 

been well developed by John T. (Jarrity in an article describing 
a study conducted by McKinsey &■ Company on the experiences of 
twenty-seven major companies in 13 different industries. 

These companies have invested on the aggregate over $100 
million a year in automation and all have had at least four years 



'Garrity, J. T., Top Management and Computer Profits. 



Harvard Business Review, 



July- Aug 1963, 6, 
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computer experience. 

The survey sought to discover each company’s opinion on the 
success of the venture based on the criteria of: 

1. Dollar Return from computer system investment. 

Long term indirect benefits. 

3. Range and scope of applications currently using the computer. 

The results were quite decisive. The companies fell into two 
distinct groups; a group of nine had very successful results and a 
group of eighteen whose results were marginal at best. There were 
none that were moderately successful. 

In order to isolate the basic factors that determine the 
successful operation, the survey used six areas of investigation 
for a comparative analysis. These areas were: 

1. The quality of executive leadership provided for the 
computer systems effort. 

2. The soundness of planning and control tools used in 
managing the effort. 

3. The degree of operating management involvement. 

4. The caliber of the computer systems technical staff. 

5. The role of the corporate computer systems staff. 

6. The equipment strategy. 

In each area the question and responses were divided into two 
categories; those responses which reflected major differences 
between the successful and unsuccessful companies and those responses 
which reflected basic similiarities. 
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Mr. Garrity concludes that there were eleven major differences 
between the successful and unsuccessful companies. 

In the successful companies ^he executive management devoted 
a reasonable proportion of £hc ir time to the computer system, 

<v 

subject to its cost and potential in relation to other executive 
responsibilities. This did not mean that they were involved in 
the technical aspects of development, but in the management 
problems involved in integrating the computer system with the 
management process. This means they spend time reviewing plans 
and progress and insure that proper results are achieved. 

Before any application is initiated in the successful company 
a careful feasibility study is conducted to insure that the 
application is cost effective and practical. Once a project is 
initiated, project development and progress is followed closely by 
the corporate management including the chief executive. These 
leading company executives were continually looking for methods to 

strengthen tghei r management control over the computer systems 

k 

effort. 

In the area of operating management involvement in the computer 
systems effort there appeared the greatest divergence between the 
two classes of company. 

The lead company® s operating management took a very active 
role in the selection, planning and manning of the projects under- 
taken. This appears to be due to several factors, including top 
management’s attitude of fostering effective staff-line relation- 
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ship and an atmosphere favorable to an innovating, inquiring 
approach.^ In addition, top management has clearly defined the 
operating executives role in the computer system effort. 



The role of the technical staff is very clearly defined by 
the executive leadership of the lead companies. The need for a 
competent and well staffed technical capability was recognized. 
These companies not only provided this but further supplemented 
their systems skills by including management-sciences personnel 
on the staff. 

Each successful company in general, provided a computer exec- 
utive who could function effectively with limited technical knowl- 
edge at the first or second level below the chief executive and a 
computer systems manager who had extensive technical skill at the 
next level below the computer executive. This appeared to provide 
sufficient technical effectiveness with proper management control. 

In general, the lead companies, placed the computer system 
organization in the corporation at the division level with as 
little disturbance to the company organization as possible. This, 
however, did not seem to bj|) a major factor in the success of the 
company 1 s effort. 

It is also noteworthy that all the companies, successful and 
unsuccessful tended to have the same equipment strategy. 

The overall basic factors derived from the survey appear to 
show that top management must correctly assess the computer 1 s 
potential and provide the continuing management guidance that it? 
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requires. 

We must therefore conclude that the answer to "Who” part of 
the question of control is that all management from the chief 
executive to the operating and technical staff must take a active 
role in the operation with top management taking a lead role. The 
answer to the '•How*' part is much the same, top management taking 
an active part in establishing policies and guidelines and the 
close cooperation of the operating and technical staffs in carrying 
them out. 

B. OBJECTIVE 

It is the intention of this paper to describe the functional 
steps in the development of an automated system and delineate the 
documentation required. 

The logical sequence of events in this development are: 
Planning, Analysis, Development, Evaluation and Operation of the 
System. Planning will include the problem definition and study to 
determine the feasibility of the solution. Analysis is the detailed 
study which determines the method of solution of the problem. 
Development would be the program preparation. Evaluation can be 
considered the test to determine if the solution to the problem is 
correct and adequate. Operation is using the system as designed. 
Each will be considered and the documentation requirements for 
each phase will be outlined. 

In the development of an automated system, the first consid- 
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eration must be given to the type of unit that will perform the 
development. This unit may be internal to the organization 
requesting the development such as the computer system division 
of a activity or may be an external activity contracted to perform 
the automation such as commercial commercial consulting firms. In 
either case the unit performing the development must be properly 
and adequately staffed. This means the proper mix of systems 
analysts, operations analysts, system programmers, and technical 
writers with adequate experience in the field of program develop- 
ment. Obtaining such a qualified group may be a major problem 
since these type of skills are in great demand. One consulting 
firm known personally to this author has a policy that it will 
hire only individuals who can substantiate five years experience 
in their respective field. It is assumed for the purpose of this 
paper that this important function is available and competent. 
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CHAPTER II 



PLANNING 

The planning phase of the development can be considered the 
problenu.definition and problem analysis phase. It consists of the 
system requirement development (determination of the problem), the 
design study (problem definition and analysis) and the design 
review and approval. The system requirement is generally deter- 
mined by the activity or organization desiring automation of a 
function (hereafter called the user or user activity). The unit 
or activity performing the analysis and programming will be known 
as the developer or developing activity. 

A. THE SYSTEM REQUIREMENT 

The initiation of an automated system will be by users 
recognizing that their present method of operation is inadequate, 
inefficient or ineffective. The question that usually starts a 
new approach is; ,, Isn 8 t there a better way?’* The answer is 
usually - Yes. 

The general context of the example given in this paper will 
be that of a Naval activity, however, the same basic problems and 
solutions will arise in almost any field. 

The system requirement document must provide a clear and 
concise explanation of the problem. It must define the objectives 
of the system and describe in detail the present method of oper- 



ation. It must describe the present deficiencies, the data avail- 
able and the desired goals, including when the new capability is 
required. 

A description of the requirement is a vital part of the 

•*> 

system analysis and care must be taken that adequate information 
is provided to insure that the correct problem is analyzed and 
solved. The user prepares this document without the assistance 
of the developer. This is done to insure that only the users 
concept of the problem establishes the requirement since he is 
generally oriented functionally and is able to define the problem 
that he wishes solved. If the assistance of the developer is used 
there is the possibility of distortion of the problem to fit the 
developer 1 s preconceived concept of operation. Thus, the require- 
ment document must contain the requestor* s concept of operation 
providing a non-technical description of the capability required 
and specifying what tasks are desired. These tasks refer to the 
various phases of development of the automated system. This may 
range from a feasibility study to the complete analysis and 
implementation of the system. 

This requirement document must contain an identification 
number or code that will indicate the activity requesting the 
project. This may be an internal or external activity. As an 
example, there may be requests from the control division or the 
Technical division of the activity performing the function of 
automating or from an external activity. Each may be assigned 
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a code for identification and cross reference. A code that 
indicates the classification of the function, such as, operations. 
Intelligence, communications or logistics should also be assigned. 
Any system of identification and ready reference would be accept- 
able if nit insures clear, concise classification. The method de- 
scribed above is currently in use in the Naval Command and Control 
System. It provides a two digit code for the requesting activity, 
a single letter code for the functional area and a serial number 
indicating time of receipt. An additional code could be used for 
priority classification. 

A noun title would usually be assigned for ease of nonauto- 
mated reference. 

In addition, the priority and date capability is required 
must be included. These factors will assist in determining the 
feasibility, timeliness and appropriateness of the project. 

B. DESIGN STUDY 

Upon receipt of the system requirement by the systems analysis 
group, a design or feasibility study is conducted. This study 
should be conducted in close liasion with the user. 

The study group will analyze the requirement in detail, 
defining the present system, the data inputs, the data formats, 
detail processing being conducted, output data and form of pres- 
entation. 

A definition and explanation of the present activity’s 
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responsibilities and the desired capabilities to be provided by 
the new system must be made. 

An analysis will then be made of the organizational relation- 
ship within the activity by the use of information flow analysis 
including all interactions within the activity and wit|| all 
concerned parties outside the activity. Information flow analysis 
concerns itself with data and document transmission without 
considering organizational structure. It is a derivation of pert 
analysis on documents and data. 

Problem areas such as duplication, dual responsibility and 
inconsistencies will be described. 

A comparison will be made of the organization functional pro- 
cedures with the information flow analysis to clarify differences 
and provide background for recommended revisions. 

This may also be called a 'Systems analysis. It involves 
collecting, organizing, analysing and evaluating the pert inant 
facts about the present system and its environment. This is 
accomplished by determining the input and output requirements of 
the present system, the sources of data, the method of processing, 
(eg. ADP, EAM Manual, etc.) the frequency and volume of the data 
transactions. 

Now for the development of a new system, the systems analyst 
must be fully cognizant and responsive to acceptable standards of 
procedure. The analysis is conducted by the developer with the 
cooperation of the user staff. 
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Figure 2 • Message specification sheet. 
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The most generally accepted method of conducting an analysis 
involves the following series of logical steps? 

First, the facts or data must be assimilated. This is done 
by interviewing personnel and observing activities performed in 
the system. 

Second, obtain sample copies of all data inputi?and outputs 
- i.e. documents, files, including statistics and processing time, 
frequency and volume encountered during the operation. 

Third, learn the processingj^bperations and determine how and 
why each item in the system is processed. 

Fourth, organize the data Obtained into a systematic and 
logical flow, noting redundancies, overlaps, duplication, omissions, 
and the development of new concepts proposed or informally initiated 
by the user personnel. 

Fifth, review the data obtained with the personnel involved 
to determine if data is correct and flow developed is a true 
representation of this data. The key to successful completion of 
these five steps is complete and clear documentation as illustrated 
below: 

Document Specification and Disposition Form . This is a standardized 
form for presenting detailed specification and disposition of any 
communication. It provides a sequence number for integration into 
the flow analysis. The form is of a general nature therefore may 
be used by virtually all analysts for all types of communications. 

It provides a card code, form number, and title for identification 
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and cross reference. The analyst prepares this form as he is 
interviewing personnel responsible for preparation and disposition 
of the document under consideration. He identifies the activity 
currently processing the document, the processing action, the 
physical form, the frequency of processing and disposition. With 
this form he is able to follow the sequence of actions on each 
document within a specific activity or follow any document as it 
is processed by each activity. 

Figure 2 is an example of this form. The document is a 
'•request for additional skill'* from the planning department to the 
manpower department. As indicated the manpower section must prepare 
a typed answer. This action is done on a quarterly basis. There 
is no special time requirements on the action. 

This form, along with a completed copy of the document provide 
the input data for the system analysis. The forms and copies of 
documents are edited, summarized, analyzed and flow charted to 
provide a comprehensive, quantified understanding of the data flow 
throughout the organizational area being considered. 

The conclusions from this analysis will provide docimentation 

on location characteristics and relationship, file analysis, network 

* 

and location load analysis, document activity analysis, and flow 
analysis. 

Location Characteristics and Relationships . This documentation will 
include description of files and the type, frequency, volume and 
special requirements of the data processes at the location. It 
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Figure 3 Network data load detail report. 
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Figure 4 Document activity report. 



indicates the function of the location as to origination, control, 
storage, or relay point in the system* The relationship of various 
locations in the system provide useful information in deciding 
potential for integration or centralization. The description of 
the files at each location may indicate the need for change in 
storage media or reduction of redundant information. 

Network Load Analysis . The data from the document specification 
and disposition forms are sorted by station identity, form number 
and card code to develop reports for each activity by identity, 
code, frequency of processing and special time requirements. The 
network data load detail report shown in figure 3 list all docu- 
ments, forms and reports processed by an activity (or unit) grouped 
by identity code, frequency of processing and special requirements. 
The volume of documents is listed by frequency of processing and 
converted to a monthly basis to facilitate comparison among activ- 
ities. From an analysis of the volume associated with each identity 
code, the analyst can determine the primary function of the activ- 
ity under consideration. Summary reports may also be prepared 
showing the total data flow network and the relationship of each 
activity to the overall network workload. 

This form indicates that Station No. 2 processes eleven types 
of documents, each on a monthly basis and a total volume of forty 
per month. 

Document Activity Analysis . The analyst may use the document 
activity report shown in figure 4 to follow the document flow 
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Figure 5 Event-type flow list. 



between different data processing areas, functional areas and 
activities. It identifies documents processed at a particular 
activity and separate listing can be prepared for documents created 
and used by the same unit. The degree of potential integration 
within and between functional activities can be established from 
this report. Independent activities will be highlighted because 
they have little or no transfer of documents to or from other 
activities. Closely interrelated data -processing activities in 
several units indicate a strong case for centralized processing, 
and vice versa. 

The document activity report illustrated indicates that form 
no. L0CC050, a requisition has interactions within the Data Services 
station (2200) and also with stations no. 8400 & 9300. 

Flow Listing Analysis . This analysis uses the event-oriented 
approach and emphasizes the fact that an event creates a document 
or action at a particular activity and focuses the analysis on the 
chain of related events as illustrated in the event-type flow list, 
figure 5. It shows a particular event and its sequence in the 
related chain of events by activity and document identified with it. 
The processing actions taken as a result of receiving a document at 
a particular activity are identified on the flow list as affecting 
the document, alone or as also initiating some other operations. It 
will also identify incomplete event chains. 

The Flow Analysis listing provides a chronological list of 
events. As an example the Data Services section conduct events 
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numbers 4-0 to 4-341000 using document numbers FiLTOBO, FIL60, 
FILT180 and L0CE110 on which they prepare document FIL60, COMPUTE 
DOCUMENT FIL61, prepare document FIL180 and compare this with 
document FIL150. The final disposition of this series of events 
is to the industrial Engineering Division. 

Comments and recommendations are made from these analyses 
that will advise on adequacy of the present capability and recom- 
mend possible improvements to the present system. These improve- 
ments will be of two types; (1) Improvements that would not require 
the use of an automated system and (2) Improvements that would 
require the use of an automated system. 

The design study will include complete organization and infor- 
mation flow charts of both the present system and the proposed 
system if required. See Appendix A for recommended format of the 
report o 

C. DESIGN REVIEW AND APPROVAL 



The design study report will be presented to the user top 
management for review and approval. The systems analysis group 
together with the user personnel assigned to assist in the design 
study should be available to clarify any phase of the report not 
understood. This approval will signify that the user and the 
analysts understand the requirement and agree with the proposed 
developmental approach. It should be stressed here that this 
approval does not bind or fix the design irrevocably. It is 
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obvious that if the system is complex and dynamic there will be 
changes required. These design changes may be major or minor since 
the design study will not generally do as detailed an analysis as 
is required by the complete operational and functional design. 



% 
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CHAPTER III 



ANALYSIS 

The analysis phase of development is the connecting link 
between the design and programming of an automated system. It is 
much more detailed in that it provides analysis of the problem 
from a functional point of view, that is, it describes the system 
being developed by the functions or tasks that are being automated 
and describes how these functions and tasks will be automated. 

. DETAILED SYSTEMS ANALYSIS 



With the approval of the design study, the more extensive 
systems analysis may be initiated. This is accomplished in two 
phases, i.e.s the functional analysis and the operational analysis. 

The first step in conducting these analyses is the preparation 
of a "Plan of Attack" or development plan. This development plan 
will give estimates of time and effort required to develop the 
system. These estimates will be the best judgement of the analysts 
and programmers of the scope and range of the system and will be 
prepared by phases. They will contain man-day (month, year) effort 
required to accomplish the phase. Time tables and "milestone" 
dates by which the progress of the development may be measured will 
be included. It should be emphasized here, that this is only an 
estimate of the effort required based on the best information 
available to the analysts. The phases will be divided into the 
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analysis phase, the coding (Programming) phase, the testing phase, 
the data collection /convert i on phase, training and turnover phase. 
Figure 6 provides a sample of time phasing that illustrates the 
sequence of events and actions. 

The analysis phase progress can only be measured by the 

expected number of manhours to complete the phase, the coding phase 

% 

progress can be measured by the nuber of coding instructions 
completed in a certain time period. The present “State of the Art** 
provides very little data on what is an average number of coding 
instructions or steps that should be completed in a specified 
period. Some programming organisations use ten '‘debugged* 1 pro- 
gramming steps per day as a standard. This is a very uncertain 
measurement since a great deal depends ora the complexity of the 
program and the interactions necessary with other systems. In the 
itest and checkout phase the measurement of progress (and again an 
unsure one) is the number of hours of computer time required to 
make the system operable. Some of the possible criteria for 
measuring efficiency and progress in the coding and system check- 
out phases may be; 

1. Minimum programming effort i.ej the simplest method for 
coding to provide minimal coding and debugging time. 

2. Program execution time minimum i.e» minimal computer 
running time. 

3. Insure that the program occupy as little computer memory 
as possible. 



4. Provide at program that is flexible , i.ej insure the 
program is relatively easy to modify or change. 

Each of these criteria or constants will require the analyst 
to consider alternative methods of system development. Figure 7 
contains a recommended format for development plan. 

% 

1. Functional Analysis 

A comprehensive scientific investigation to define the problems 
and the most feasible method of solution from a functional stand 
point is now conducted, taking into consideration both effectiveness 
and cost. It will include a more detailed review and analysis of 
the user requirements and of the information flow than was completed 
for the design study. The design study will be the starting point 
for this analysis. 

With this design study the analyst must describe the scope and 
function of the system. Using the information flow analysis 
completed in the design study, a comparison of the document commu- 
nications process is made with the formal organizational communica- 
tions process that will enable him to discover duplication, redun- 
dancies and inadequacies that were not readily apparent during the 
design study. This will allow him to design the new system allevi- 
ating many of these problems. This may appear to be redundant 
effort in view of the design study effort, however, it is advisable, 
at this later point in the development, to review the flow analysis 
to determine if any changes in concept corrects deficiencies dis- 
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covered. There are several methods available to perform these 
tasks. One method may be the use of ‘‘automated analysis." ' The 
Rand Corporation had developed a system called "Auto sate" (Auto- 
matic Data System Analysis Technique). Autosate is an electronic 
processor for organizing and analy&ng the facts collected about 
the flow of data in the system. It provides simplified and 
standardized input collection so the data collection may be accom- 
plished by a non analyst. It performs most of the routine tasks 

*r 

m 

of checking, tracing, reconciling, verfiying and flow charting of 

da^ta so that the analyst may conduct the more rigorous higher 

level analysis and creative design work. 

The International Business Machines Corporation has also 

developed a systems analysis program in connection with their 

4 

Documentation Aids System. This particular analysis program is 
limited in that it cam be used only to analyze an automated system. 
It is designed tos 

1. Improve and update documentation of existing programs. 

2. Ease maintenance problems by providing up to date program 
documentation. 

3. Eliminate certain clerical and routine functions associated 
with documentation and conversion. 

3 

Gregorj r , R. H. and R. L, Van Horn, Automatic Data Processing 
Systems - Principles and Procedures, 1964 g 190. 

^JBM Reference C2Q-1612, Kingston, Neir York (1964) 
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4. Improve programming efficiency by the standardization of 
documentation techniques. 

5. Encourage the user to reprogram in a higher-level language 

5 

as an example, Fortran, Algol and Cobol. 

This makes it ideal for redesign or updating of an automated 
system but provides little assistance in development of a previously 
nonautomated one. 

Other methods of analyses are those of Simulation, run diagram- 
ming, structural flow charting, or use of decision tables. 

Simulation is a well known technique which flows through, 
step by step, the events that are expected to occur in a proposed 
system using prior experience, logical forecasting and probability 
theory to estimate the timing, number and type of occurrences that 
will result from various combinations of input data. This is a 
far less expensive process than actual operational development. 

Run diagramming presents a general overall view of the major 
functions of a system. It shows fundamentally in short English 
language statements how the various files, data and processes 
interact in the system. It is a very much simplified version of 
the programming flow charts which provide much higher level of 
detail. Figure 8 gives an example of a run diagram that shows the 
procedure for updating an inventory file and the method for reor- 
dering on a periodic basis. Each rectangular box represents a 

5 Ibid 
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Figure 11 Decision table for inventory file updating. 
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run, i.cj the processing of one set of inputs. The arrows show 
whether a file or document is an input to or output from a run and 
the numbers indicate the volume. In Run 1, the data in the inventory 
transaction file are sorted into sequence by stock number and trans- 
action type. In Run 2, both the sorted inventory transaction file 
and the inventory master file are inputs to processing. The outputs 
from processing are the updated master file of a use in the next 
cycle, lists of changes applied, a reorder list, and errors. Error 
may consist of transaction records without corresponding master 
file records, records out of sequence and negative balances. 

The structural flow charts mentioned above are prepared during 
the overall design of an automated system. They describe the time, 
quantities and type of inputs, processing, output and files. They 
may be differentiated from programming flow charts in that they 
give a general description of the process in more detail than the 
Run diagram but stop short of presenting program instruction 
sequences. A sample structural flow chart is shown in figure 9, 

It illustrates a method for updating an inventory master file. 
Identification names (numbers) are given to the major blocks, 
documents and files , This name or number should be used on all 
flow charts to identify the same items. This flow chart shows 
the volume of activity, i,e» the number of records or the times 
each path is used. As an example the inventory master file con- 
tains 1000 records and the nuaber of items below the reorder point 
is sixty (60) as indicated on the (, yes M branch from the test for 
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inventory balance. These figures are useful for calculating work 
load and processing times. 

Decision tables offer a more versatile display of diagramming 
various sequences of action than does the structural flow chart. 

It allows the illustration of several alternate sequences of action 
through which one can clearly observe the obvious path through the 
program. In flow charting it is difficult to obtain such a path 
since one must often consider all the prior conditions made that 
may influence the path of the process. The use of decision tables 
solves this problem, in that all prior conditions are readily 
displayed. Figures 10 and 11 provide a comparison of a flow chart 
and a decision table for an Inventory file updating procedure. 

The flow chart indicates several decision diamonds in series 
to describe the inventory file updating. It is necessary to refer 
to several flow charts in order to follow the complete inventory 
file process. This procedure becomes very complex. As an example, 
if the transaction type is greater than 3 it is necessary to refer 
to chart A-l.2.2. If it is less than 3 a three decision diamond 
is necessary. The numerals indicate the number of expected 
actions. With the decision table this confusion is not apparent. 

The decision table is set up with three sections, the 
conditions, the rules and the actions. The conditions correspond 
to the contents of the decision diamond of the flow chart, but 
providing more branches or alternatives for action. The actions 
represent the processing blocks of the flow chart presented in the 
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sequence of execution desired. As an example, the sequence of 
execution for a transaction record for which there is a master 
record and for which the type of transaction (purchase-Rule five) 
would bet 

1. Match transaction record number with master record number. 

2. Match transaction type with rule number. 

3. Perform actions indicated by rule number. (In this case 
transaction type three indicates rule number five) 

4. Perform actions s 

a. Add purchase order to balance on order. 

b. Read inventory transaction file record. 

c. Go to inventory file update table, (i.e. - Return 
to beginning of this table and read next transaction record.) 

Two advantages of the decision table is that the condition 
and action are independent and all conditions are tested for the 
applicable rule before any action is executed. 

These methods of analysis may be done singularly or jointly to 
perform the analyses suitable for the situation or problem being 
studies. 

2. Operational Analysis 

This phase of the analysis will be done in conjunction with the 
functional analysis phase and will investigate and determine the best 
operational procedures to be used in developing the system. It may 
use various "operations analysis" techniques such as Queuing theory, 
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Linear and Dynamic programming methods and Monte Carlo methods. 

Caution must be exercised here to insure that the solution fits 
the problem. Often analysts become too involved in an extremely- 
sophisticated solution to a problem that does not require this 
sophistication. If the solution is too complex to understand it 
will not be used. The analyst must always keep in mind the problem 
to be solved and solve it in the most effective, efficient and 
least complicated method possible. ‘‘Don’t solve the wrong problem,*' 

The techniques of Operations Analysis are widely known and 
used within the data processing environment. An example of the 
use of Queuing theory and Monte Carlo methods in automated devel- 
opment could be the simulation of data elements entering the 
system for use in a subroutine. These elements may have an arrival 
rate that may approximate a certain distribution function. The 
subroutine may process these elements at a certain service rate 
which would approximate an exponential distribution. Using various 
assumed probabilities and Queuing theory, fairly accurate predictions 
can be made for processing times under most conditions. This is 
sufficient to indicate that competent systems analysts must be 
familiar with these methods and able to make sound judgments as to 
when and how to employ them ah obtaining solutions to the "problem," 

3, Procedures Development 

During the analysis phase the procedures development plan will 
be made. This will be in the form of a formal functional descript- 
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ion of the system in a prescribed format. This may be described 
as a "documented analysis of the area under consideration for 
automation"® including all conclusions and general specifications 
for the proposed system. It must be written so that the user 
(possibly non AUP orientated) will have a clear understanding of 
the impact of the proposed system modification and encourage user 
participation in the project development. Below is a summary of 
the contents of this document. Appendix B is a complete outline 
of the format. 

In providing a clear statement of operational capability the 
functional description wills 

1. Provide a basis for defining the work to be accomplished 
and the program to be developed. 

2. Provide in writing a basis for mutual understanding of 
requirements between the user and the system analyst. 

3. Assist in obtaining concurrence between the user and the 
developer. (System Analyst) 

4. Provide the user with information requirements necessary 
for data collection and preparation. 

To accomplish this, the functional description will outline 
existing procedures, including personnel responsibilities, present 
equipment, files, system cycling frequency, time delays and a 
block diagram description of information transmitted from data 
receipt through processing and use. Utilizing the techniques of 

^Naval Command Systems Support Activity Instruction 5230. 1A 
17 July 1964. 
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information flow analysis in conjunction with the methods of 
simulation, run diagramming, flow charting and decision tables 
described above, the documentation will outline the development of 
the proposed system and present a comparison of the two systems. 
Alternate recommendations will be described with consideration 
given to the costs and requirements of the desired system. Details 
will be provided in man-power requirements, machine time, equipment 
requirements and processing times for development and operation of 
the system. These details must include present functions or 
operations that are being deleted and functional descriptions of 
new operating procedures including a capability or grade level of 
personnel required. 

A summary of the impact on the user command as a result of 
the installation of the new system will be provided. 

A detailed description of the following elements will be 
provided! 

1. Equipment required. 

2. System programs and subprograms to be used. 

3. Data requirements including files, formats, frequency 
and sources. 

4. Data transformation - a description of the techniques 
and processes for converting input data into required formats. 

5. Output - report and display formats will be described 
including user, content of report or display, purpose and frequency. 

6. Query capability - a description of the query procedure 
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including types, limitations and flexibility* 

7, System capacity - specifications for data Volume, accuracy 
and response time available* 

8* Manpower requirements - A summary of the requirements to: 
a* Establish the data base for the system* 

* 

b. Maintain data base, 

c. Operate and maintain the program. 

The completion of this report, its review and acceptance of 
the concept of development and operation by the user completes the 
analysis phases and provides a firm decision on the concept of the 
system development. The developer now has a solid base for project 
completion and the user has a clear, firm description of what will 
be provided as an automated system. Hereafter; there can be no 
change in concept or major modification of method of development 
without a complete reappraisal of the entire project. 

4. Data Collection 

Data collection will be the main responsibility of the user. 
The format design necessary will be prepared by the system analysis 
group, and will include detailed instructions for preparation. The 
raw data to be received will be outlined and data card columns, 
number of data cards required and frequency of preparation will be 
determined. 

Using as aids, the data collection format, flow charts and 
decision tables prepared in the design and analysis phases, the 
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various standardized inputs formats are designed. Here the ingenu- 
ity of the systems analyst is taxed. He must design the input 
formats that are readily understandable by the user, that is, 
avoiding the requirement for complex conversion of the raw j^c.ta into 
the technical computer language by the user. Yet, they must 
contain «complete information properly sequenced so as to permit 
relative ease of conversion to the computer language and key 
punching format by the analyst. There must also be the attempt 
' to combine logically related data in a single format, but avoid 
design of extremely complex or unwieldy documents. The effect- 
iveness of the program will be no fetter than the validity of 
the data entered, therefore, it is obvious that this phase is 
critical to the successful operation of the system. 
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CHAPTER IV 



DEVELOPMENT 

With a firm concept and system design in hand, the analysts, 
system programmers, and programmers may commence actual program 
development. This will consist of preparing detail program flow 
charts, program coding and checkout. This development is accom- 
plished in two distinct areas, hardware development and programming 
development. 

A, HARDWARE DEVELOPMENT 

Jf required, hardware development may be conducted concurrently 
with the analysis* Care must be exercised that selection of 
equipment be accomplished without preconceived ideas on type of 
equipment. Equipment must fit the system. The system should not 
be designed around equipment. 

In certain areas, however, such as command and control, very 
large capacity equipments are in use and development of subsystems 
within the command and control area must have the equipment 
configuration as a preset parameter. 

Hardware development is a large and very complex study. 

Hardware manufacturers are continuously conducting research to 
design and produce new equipment for faster more accurate process- 
ing method. Apparently the main problem in system development is 
being able to define the requirements well enough to choose the 
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proper equipment 



B. PROGRAMMING DEVELOPMENT 



The term programming may be considered in two ways? that of 
problem analysis and that of writing the program instructions. In 

this paper it refers to writing the program instructions. The 

% 

functional description is translated into detailed flow charts and 
a series of subprograms and subroutines. Flow charts mentioned 
here are programming flow charts. Programming flow charts describe 
the specific operations and decisions that are performed in a 
stored memory program. 

The flow chart symbols shown in Figure 1 are used for the 
programming flow charts as well as the structural flow charts. 
Various decisions must be made prior to actual coding of the 
system. The analyst must decide on the language in which the 
system will be written. Here, he has a wide variety of choices. 
However, he must consider several parameters. These may bes the 
type of problem - scientific, business or mathematical % the 
frequency with which the problem must be solved - real time or 
delayed processing application i the type of input - direct from 
source documents or via some intermediate compiling device. If 
the problem is scientific a programming language such as FORTRAN 
or JOVIAL may be required. For a business application COBOL may 
be used. These are only a few of the criteria that may be 
considered. Many more could be necessary depending on the type 
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and complexity of the problem. Up to this point in the analysis 
no mention has been made as to the hardware configuration. It was 
pointed out in Chapter IV, Section A, that the analysis to this 
point need not consider the hardware configuration. The analyst 
must now give this consideration. Size and speed of the computer 
may be a limitation. The input media may dictate certain 
programming methods. An example would be the methods used in 
programming for sequencial processing versus those used for random 
access processing. 

Sequential processing uses data records that are in a series 
storage such as magnetic tape which would require methods of 
sorting and editing that scan the complete file in order to extract 
or correct a single record. Records must be sequenced in the most 
efficient manner so that information required most often is near 
the beginning of the tape. 

Random access processing will not have this limitation in that 
each record or bit of information can be obtained independent of 
other information. 

Another consideration will be the availability of compilers 
or assemblers. This will dictate the use of either a problem - 
oriented language (machine independent) or machine - oriented 
language (machine dependent). The use of a machine - oriented 
language requires little or no translation into computers numeric 
ordi^ code. The mnemonic (alpha) codes would require translation 
on a one for one basis. The use of a problem - oriented language. 
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such as Fortran, Cobol, Algol or Jovial, however, requires the use 
of much more elaborate translators and e p : I d convert each 
program instruction into one or several machine instructions. It 
is obvious that if these translators and compilers are not avail- 
able, then these also must be developed. This will add to the 
programming complexity. The trade offs of simplicity and efficiency 
of the machine - oriented language against the sophistication and 
versatility of the problem ~ oriented language must be considered 
in the light of the problem to be solved. 

Generally the development of an automated system to perform 
some set of objectives will not stand alone. Automating an 
inventory control function will usually be done in conjunction 
with the automation of the procurement, disposal, accounting and 
financial control functions to create a complete system. Also 
other unrelated functions may be developed for the same organiza- 
tion or activity. In order to design and develop a complete, 
integrated system it is necessary to create, where ever possible, 
standardized routines and procedures. These routines usually 
perform the executive function of an integrated system. The basic 
system monitor is designed to perform ^housekeeping'* functions 
such as i execution control which consists of standardized routines 
for loading and sequencing programs, input-output control, inter- 
computer communications control and time sharing program control. 

The availability of these routines in an integrated system 
eliminates the necessity fer detail programming to control these 
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operations. It does, however, demand the adherence to standardized 
programming rules. This standardization generally simplifies the 
programmers task but may have the disadvantage of less efficient 
operation of the individual program. This decrease in efficiency 
is usually acceptable since the use of standard routines will 
increase the overall efficiency of the integrated system. With the 
various '•tools” mentioned above, the programmer is able to translate 
'from the detailed program flow charts and decision tables to the 
programming code. When writing the source program, the programmer 
must define each data file and table to be used by the type of 
file-card, tape or diskj type of processing - random or sequential 
and the method used for spacing and over flow. 

He must specify the input - output requirements including 
the Macro-Instruction controls for insertion and retrieval at the 
proper point in the program. Utility routines, such as card to 
tape, tape to print, disk to tape, etc;, must be properly called 
and sequenced to provide a smooth integration of the computational 
and input-output operation of the program. 

Consideration must be given to querying methodology including 
types, limitations, flexibility, report formats and output displays. 

The programing development will provide extensive document- 
ation on all programs. This documentation is the heart of the 
operational process of the system. It will contain a user or staff 
(nonADP) section which will provide a system description giving 
the capabilities and limitations oriented toward users having no 
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technical background in ADP . It will contain the description of 
system inputs including the source , the type (forms, data cards, 
punched tape, etc») the volume and frequency. It will also 
contain the system output, describing in detail the type, (report 
forms, data card, magnetic tape, visual displays, etc.) format 
and frequency. 

The technical operations 111 section will be written in more 
technical language for use by the maintenance programmer and ADP 
operations personnel. It will contain detailed flow charts, the 
symbolic and machine listings of each program or subprogram. 

Detailed methods of query preparation for gaining access to 
information other than from scheduled reports procedures will be 
provided. 

The ''system operation " 11 section will describe the computer set 
up and operation providing detailed online input/output processes 
such ass printer, card-reader, type units, display equipment, etc.. 
It will also provide details on data arrangement, tape mounting, 
sense switch setting, running time, output disposition, error 
check, EAM procedures, control procedures, etc.. Appendix C gives 
a complete outline of the final documentation. 

C. TESTING AND CHECKOUT 

During programming development the various subprograms, 
utility programs and subroutines must be tested to insure accurate, 
properly operating systems. This is usually referred to as 
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"debugging.” It will involve checkout on the computer for which 
the system is designed. All subroutines must be tested separately 
and in conjunction with others to insure compatability of the 
system. During this period corrections and modifications continue 
in order to develop the most efficient and dynamic system possible. 
Here it is necessary to stress the accuracy and completeness of 
the changes to the program documentation. This is vital for future 
maintenance and modification to the system. 

D. MODIFICATION 

Unless an automated system is extremely limited in scope, it 
must be dynamic and contain the capability to be modified and 
changed. In order to perform these changes and modifications, at 
some future time when those originating may not be available, the 
original program documentation must be complete and clear. Proce- 
dures must be instituted that will insure that programming instruc- 
tions (additions and deletions) are fully documented when they are 
accomplished, A complete history of program development and modifi- 
cation should be available. This can Only be accomplished by 
management establishing and enforcing rigid policies concerning 
documentation standards and procedures. This is not to be done 
to preclude making changes but to insure a complete record of 
those made. 

There have been several methods developed that will automat- 
ically prepare a record of any modification made to the program. 
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Section III-B mentions two of these, Autosate and Documentations 
Aids System. As mentioned previously the D.A. System is very 
useful as a maintenance tool for automated systems. Here it would 
be ideal for modification. 

This system consists of four programs and processes source 
programs written in Symbolic Programming System (SPS), Autocoder, 
Macro Assembly Program (MAP), Fortran Assembly Program (FAP) or 

7 

Symbolic Flowchart Language (SFL) for various IBM machine systems. 
It produces the following program documentations 

1. A storage map of object decks. 

2. An analysis listing of source decks. 

3. A flowchart of source decks. 

These programs are the update program, the analysis program, the 
flow chart program, and the verification program. 

The update program is used to insert, delete or replace 
programming instructions in the source program. It performs these 
functions by a file maintenance routine. It is also used to update 
the symbolic flow chart language, conduct sequence checking and 
prepare an input tape for the analysis and flow charting programs. 

As it implies, the analysis program provides a detailed 
analysis of each program instruction giving a listing denoting 
the type of instruction (relative addressing, indexing, indirect 
addressing or data defining), a cross reference dictionary of 
symbols used and a statistical analysis of the operations codes, 

^IBM Document no. H20-O133-0 (1964) p. 1. 



51 



i,e. - the frequency of occurrence of each code. 

The flow charting program generates an updated flow chart 
presenting the logic of the source program and uses the output of 
the analysis program to produce the “symbolic flow chart language." 

The verification program is designed to assist the programmer 
in comparing the source program with the current object program by 
producing a storage map which presents the contents of core storage 
after the object program is loaded. It provides location sequences 
and identifies all program patches made to the object program. 

The use of these four programs should substantially ease the 
workload of the maintenance programmer. It is again pointed out 
that this simplification can only be accomplished if the original 
documentation is reliable. 

With the completion of the development phase the automated 
system is available for evaluation and use by the user activity. 

In order to consolidate the documentation described in this paper 
Appendix D is provided as a summary of all documentation needed to 
maintain and modify the system when required. 
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CHAPTER V 



EVALUATION AND OPERATION 

With the completion of the testing and checkout phase, the 
system is theoretically ready for operational evaluation. This 
should be done under actual operating or simulated operating 
conditions for a specified period of time. These evaluations 
tests must be conducted by operations personnel under the super- 
vision of the systems analysis group and observed by the users. 
This will give all concerned the opportunity to evaluate and 
become familiar with the system. It. will also provide a vehicle 
for communication of criticism or suggestion for more efficient 
operation. Cost of effectiveness studies may now be conducted to 
determine the increase of functional efficiency gained by the 
installation of the automated system. The final acceptance of 
the complete system is formally prepared releasing the developer 
from further responsibility. The continued maintenance and 
modification of the system will now be the responsibility of the 
user activity. 
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CHAPTER VI 



CONCLUSIONS AND ACKNOWLEDGEMENTS 

While the technological developments in the field of auto- 
mation have advanced by great strides in the past twenty years, 
the administrative progress has moved very slowly. The great 
speed and versatility of present day computers are being hindered 
by the lack of proper administrative control. 

The day of program development by the ’'seat of the pants*' 
programmer has past. Automated systems have become so complex 
and the problems that are being solved are so complicated that 
systems development requires sophisticated procedures that can 
only be followed by proper and adequate recording as development 
progresses. 

An automated system without complete documentation will fall 
into disuse because the reprogramming effort required may be as 
great as for the original development. 

If adequate documentation is provided, including a complete 
system description, flow charts, block diagrams and anotated 
listings of all systems and subroutines as is contained in section 
VII, the modifications and/or changes may only require the efforts 
of relatively few experienced analysts and programmers. 

The key to successful cost effective automated systems is, 
therefore, complete, clear and timely documents produced during 
the development. 
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This paper outlines an approach to the solution to the 

problem of inadequate or improper documentation in the development 

of an automated system. It is written in an effort to promote an 

interest in this problem. There may be other approaches that are 

being used in the field of automation. There have been many 

articles written on document and data element standards as evidenced 

by scanning the recent American Computing Machinery index to the 
8 

computing reviews. However, the author has been unable to find 
any specific references to the standardization of analysis and 
programming procedures and documentation other than those mentioned 
in this paper. 

As it was pointed out, the government has taken an interest 
by advocating more stress be placed on standardization of computer 
and system development techniques. There is a great deal yet to be 
accomplished. The Data Processing System Manager has the responsi- 
bility to produce an efficient operating system. In order to do 
this he must have all the tools to perform the task. With a system 
properly analyzed, developed and documented he will be able to 
maintain efficient operation procedures. 

In conclusion I would like to acknowledge the advice and 
constructive criticism provided in writing this paper by Professor 
James B. Cowie. It has helped develop the area of interest and 
concern to me . 

g 

Association for Computing Machinery, Computing Reviews 1960- 

1963. 
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APPENDIX A 



REPORT OF DESIGN STUDY 



I. Title Page 

II. Abstract 

A clear and concise statement of the content of the document. 

III. Table of Contents 

IV. Introduction 

A. Background 

1, Requirement - An analysis of the requirement contained 
in the project request presenting clear definitions 

as to statements contained therein. 

2. Staff Responsibilities - A definition and explanation 
of the present staff responsibilities and the desired 
capabilities to be provided by the completion of the 
subject project. 

V. Analysis 

A. Environment 

1. Organizational Relationships - A reference may be 
made here to information flow and the various inter- 
actions of the staff with other users. 

2. Problem Areas - A definition of problem areas encountered. 

B. Present Methods and Procedures - A discusion of the 
present staff methods and procedures in performing the 
functions outlined in the subject project request. 
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C. System Analysis - an analysis of the present system and 
proposed system development. 

VI. Comments and Recommendations 

A, Present Capabilities - A statement and analysis of the 
adequacy of the present capabilities. 

B. Proposed System Requirements 

1. Ncn-ABP - Recommendations as to improvements of present 

capabilities which would not require the use of ADP 
systems . 

2. ADP - Recommendations as to proposed improvements of 
present capabilities which would require the use of 
ADP sys terns . 

APPENDIX 1 

Flow charts of the present system. 

APPENDIX 2 

Flow charts of the proposed system, 

APPENDIX 3 

Reports on location characteristics and relationships. 

Reports on Network load analysis. 

Reports on Documentation Activity Analysis. 

Reports on File Analysis. 

VII. Glossary 

VIII. Bibliography 

IX. Distribution. 
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APPENDIX B 



PRELIMINARY FUNCTIONAL DESCRIPTION FORMAT 

A. Introduction 

The requirement. A statement of the established requirement 
with appropriate references. 

B. Existing Methods and Procedures 

1. A description of existing methods and procedures, including 
personnel responsibilities, equipments, volumes, frequencies, time 
delays and a block diagram description of information transmitted 
from the beginning of data acquisition through its processing and 
eventual use. 

2. Throughout this over-all analysis of the user*s present 
system, quantitative as well as qualitative values which support 
justification for the need of improvement must be developed. 

C. Proposed Methods and Procedures 

1. A definitive description of the capability upon which 
project design will be based. Emphasis should be placed on 
differences from the existing system. A block diagram of the 
proposed system will present an over-all view of the planned 
capability. 

2. The description of the proposed methods and procedures 
must be developed in sufficient depth to demonstrate the impact 
on man-power, machine time, equipment requirements, processing 
times and throughput. Where appropriate, alternative methods and 
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procedures will be described with subsequent discussion of the 
rationale for the final selection. 

D. Environment and Impact 

1. A summary of the impact on the user command by the 
installation of the proposed system. This discussion should include 
those elements noted in paragraph C as well as the modifications to 
responsibilities which may result. 

2. A detailed description of the following elements is 
required. 

a. Equipment needed to support the proposed system 

b. System programs to be employed 

c. Data t© support the system - volumes, formats, adequacy, 
frequency, sources. 

d. Data transformation. A description of the techniques 
and processes involved in converting the input data into the form 
required for files or for outputs. This may include a brief 
description of the mathematical models used. 

e. Reports and Displays. A description of each report 
and display, the frequency and timeliness with which it is required, 
and the events which initiate its preparation. The description will 
list the user, content and purpose of the report or display. 

f. Queries. A description of query methodology including 
types of queries, limitations, query flexibility and throughput 
time. 

g. System Capacity Requirements and Constrainst. A 
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quantitative specification of data volume, the accuracy required, 
the response time for routine and emergency situations and any 
limitations which affect the desired capability. 

3. Manpower Requirements 

a. To establish the data base required to initiate the 

subsystem. 

b. To maintain the data base 

c. To operate and maintain the programs 

d. To effectively use the capability 
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APPENDIX. C 



FINAL DOCUMENTATION OUTLINE 



Cover 
Title Page 

Detailed Table of Contents 



I. STAFF MANUAL SECTION 

A. SYSTEM DESCRIPTION 

A general description of the capability will be provided. 
It will be oriented towards an audience of users who have 

a 

no technical background in AJDP. This description will 
specify in layman terms, the usefulness of the capability 
to the user. 

B. SYSTEM INPUTS 

1. Staff sources, for data base preparation 
a. Identity of source 

(1) type 

( 2 ) expected volume per unit of time 

C. SYSTEM OUTPUTS 

1. General description 

a. Identity and description of output 

(1) type 

(2) expected frequency and volume 

(3) disposition of output 
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2. Detailed description 

a. Identity of output 

(1) Format 

(2) Explanation of symbols 

(3) Intended use 
II. TECHNICAL OPERATIONS SECTION 

A. QUERY PREPARATION 

1. Method of retrieving information and report generation 
if a standard retrieval method is not used. Otherwise, 
a reference to standard methods of retrieval already 
in use should be given. 

a. Query forms (Including formatted creation sheets) 

b. Format table 

B. SYSTEM OPERATION 

1. Console setup and operation 



a. General 




(1) 


Computers used 


(2) 


On-line input/output components used such 




ass 






(a) 


Printer 




(b) 


Card reader 




(c) 


Number and type of tape units 




(d) 


System tapes utilized 




(e) 


Disc 




(f) 


Digital plotter 
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(g) Display equipment 



b. Specific 

(1) Details related to above input/output 
components such as; 





(a) 


Use of on-line printer 




(b) 


Proper arrangements of card decks 






(deck structure) 




(c) 


Disposition of all output 




(d) 


Instructions for mounting tape, and 






tape densities (if applicable) 


(2) 


Sense switch settings 


(3) 


Approximate running time 


(4) 


Each 


separate operations performed should 




be clearly outlined 


Description of 


halts 



a. Condition (which caused the halt) NORMAL or 
ABNORMAL indicates to operator type of error 

b. Printout (which will appear with a particular 
halt) 

c. Response (action operator should execute) 

3. EAM Procedures 

a. Key punch instructions 

b. Data sorting and collating instructions 

4. Control procedures 

a. In-out origin 

b. Routing procedures for machine input 
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c. Responsibilities for control and disposition 

( cards , listings, etc.) 

5. Recommended operators run sheet (an annotated 

equipment setup summary fer operator ready reference) 
III. PROGRAM SYSTEM MAINTENANCE SECTION 

A. SYSTEM DESCRIPTION 

A description of the logical development of the solution 
by the program and the relationship between routines. 

The interrelation with other programs is defined. 

Operating system capacities and restrictions will be 
defined or referenced. 

B. DATA BASE DESCRIPTION 

A description of the basic files maintained by and/or 
for the system. 

1. Physical characteristics 

size, storage 

2. Format characteristics 

Item definitions and descriptions, format type 

3. Updating 

4. Classification 

C. DETAILED PROGRAM DESCRIPTIONS 
1. Program Title 

a . Synopsis 

b. Functional description 

c. Flow charts 
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d. Annotated listing 

e. Capacities and restrictions 

f. Halt and error conditioning 

2. Inputs 

3. Outputs 

4. Internal tables, formats, and techniques 

Description of internal tables Modification 

and updating 

COMPOOL 

5. Programmer log 
IV. APPENDICES 

Glossary 

Bibliography 

Special Additional Information as Needed 
Examples Mathematical Proofs 
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APPENDIX D 



DOCUMENTATION SUMMARY 

The following is a summary of the documentation to be prepared 
during the development of an automated system. 

A. The Planning Phase 

1. System Requirement Documentation prepared by the 
user. 

2. Report of Design Study 
Prepared by the Systems Analysts 

B. Analysis Phase 

1. Development Plan 

Prepared by the Systems Analysts and Programmers 
giving manpower, cost and time phasing estimates 
for system development. 

2. Functional Description 

Prepared by the Systems Analysts giving a detailed 
description of method for automating the system. 

C. Development Phase 

1. Technical Documentation Manual 

Developed in three sections -■ User Section, 

Technical Operations Section, System Operation 
Section and is the basic documentation for 
operations^, maintenance and modification of the 
system. 
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